A user, such as a business analyst, may use a graph-based business process language, such as Business Process Modeling Notation (“BPMN”), to create a model for a business process. Some examples of BPMN are provided by the 1.2 and 2.0 Specifications available from the Business Process Management Initiative of the Object Management Group. As compared to other process languages, such as the Business Process Execution Language (“BPEL”), BPMN may cover a greater range of workflow patterns (and provide improved expressiveness) and may also simplify modeling for non-technical audiences, such as business people. This simplification is, in some cases, associated with reduced technical constraints as compared to the restrictions imposed by other business process languages. For example, BPMN allows for modeling non block-structured flows where model entities (e.g., activities, gateways, and events) may be arbitrarily interconnected. As result, BPMN may closely align with how domain experts (e.g., non-IT professionals including business analysts) conceive of and/or communicate business processes.
Even though a wide range of workflow patterns are supported, BPMN may still have some limitations. For example, BPMN supports a “thread split” pattern, where one thread is split into a number of concurrent threads that each follow the same control flow. This can be achieved, for example, using Multiple Instances (“MI”) and/or Loop activities. Note that the same result might also be achieved using basic modeling elements such as an AND-split or inclusive OR-split paired with an XOR merge. Once a thread is split into a number of concurrent threads performing the same control flow, they may be merged back together when the number of threads was pre-determined and known at design-time. In some cases, however, the number of concurrent threads might be unknown until runtime and may, in some cases, depend on input data. In such a situation, in may be impractical to use BPMN constructs to merge the threads. For example, gateways (e.g., AND, XOR, and OR gateways) could be used to merge threads, but in this case all threads execute the same flow control (and, therefore, arrive at the same incoming edge of the gateway). As AND and OR gateways synchronize threads arriving at different sequence flow connectors (executing a different flow of control), they might lead to an erroneous execution of processes (and may also prevent processes from being terminated properly, taking up resources and even interfering with other process instances). For example, it may lead to a situation associated with a lack of synchronization.
Accordingly, methods and mechanisms for automatically and efficiently handling concurrent threads may be provided in association with some embodiments described herein.